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Abstract —Today’s large-scale enterprise networks, data center 
networks, and wide area networks can be decomposed into 
multiple administrative or geographical domains. Domains may 
be owned by different administrative units or organizations. 
Hence protecting domain information is an important con¬ 
cern. Existing general-purpose Secure Multi-Party Computation 
(SMPC) methods that preserves privacy for domains are ex¬ 
tremely slow for cross-domain routing problems. In this paper 
we present PYCRO, a cryptographic protocol specifically de¬ 
signed for privacy-preserving cross-domain routing optimization 
in Software Defined Networking (SDN) environments. PYCRO 
provides two fundamental routing functions, policy-compliant 
shortest path computing and bandwidth allocation, while ensur¬ 
ing strong protection for the private information of domains. We 
rigorously prove the privacy guarantee of our protocol. We have 
implemented a prototype system that runs PYCRO on servers in 
a campus network. Experimental results using real ISP network 
topologies show that PYCRO is very efficient in computation and 
communication costs. 


I. Introduction 

Large-scale enterprise networks, data center networks, and 
wide area networks (WANs) may be decomposed into multiple 
administrative or geographical domains E), 122), H5], Q3), 
123), ED, ID- Multi-domain networks are deployed to inter¬ 
connect community networks, data centers, corporation sites, 
and university campuses. In a multi-domain network such as a 
WAN, different domains may belong to different administrative 
units with an organization or different organizations G2, EQ, 
E), ED, DS), ID- For example, a number of organizations 
may own their own sub-networks, and those subnetworks 
are mutually interconnected to form a multi-domain network 
ID. Hence individual domain may have security and privacy 
concerns regarding revealing its domain information to other 
domains. This paper focuses on multi-domain networks that 
consist of a relatively small number of domains, which may 
appear in current enterprise networks and WANs. We do not 
consider Internet-scale multi-domain networks at this stage. 

Routing optimization, such as finding policy-compliant 
paths that have least routing cost or satisfy bandwidth de¬ 
mands, plays a critical role of network management. Recent 
advances of Software Defined Networking (SDN) has brought 
tremendous convenience to routing optimization by separating 
the control plane from routers and allowing a central controller 
to make routing decisions. Using centralized optimization, 
the controller can efficiently and effectively find a desired 
routing path for each flow and install forwarding rules on 


corresponding switches^] Although SDN simplifies routing 
optimization in a single domain, privacy-preserving cross¬ 
domain routing optimization is still a challenging problem. 
Suppose each domain has a centralized controller. The state- 
of-the-art approach to route a cross-domain flow is using local 
optimization for intra-domain path selection and BGP for inter¬ 
domain routing, such as the design in Google’s SDN B4 fl5l 
and DISCO ED- This approach protects the autonomy and 
privacy of domains. However, it is obvious that local opti¬ 
mization plus BGP may not find an network-wide optimized 
path and can hardly provide bandwidth guarantee. Another 
solution is to allow every controller to broadcast its domain 
information to the entire network and maintains a network¬ 
wide map, similar to a controller-level OSPF protocol. This 
approach causes privacy and security concerns because every 
domain has to expose its private information such as network 
topology, link latencies, bandwidth, and routing policies. In 
fact, there is no practical and privacy-preserving solution to 
the most fundamental routing problem, i.e., computing shortest 
paths, for multi-domain networks. 

Privacy-preserving cross-domain network problems can be 
modeled as secure multi-party computation (SMPC) 1301, 
m, 0, m, ed, Hi- However, general-purpose SMPC 
solutions such as SEPIA S) are extremely slow and may take 
days to complete ED ED- Therefore, customized algorithms 
are needed for the privacy-preserving cross-domain routing 
problems. 

In this paper, we present the first work for privacy¬ 
preserving cross-domain routing optimization that has reason¬ 
able efficiency in practical networks. We design and implement 
a protocol named PYCRO and its extensions to provide two 
fundamental routing functions, namely policy-compliant short¬ 
est path computing and bandwidth allocation, while protecting 
the private information of domains. PYCRO is executed on 
SDN controllers in a distributed manner and does not rely on 
any trusted third party. PYCRO is developed based on a novel 
cryptographic tool called Secure-If operations. 

The properties of PYCRO can be summarized as follows. 

1) PYCRO can compute policy-compliant cross-domain 
shortest paths and allocate bandwidth for flows while protect¬ 
ing private information of domains. The privacy guarantee of 
PYCRO is cryptographically strong.(Please see Section IVIIl for 
formal analysis of privacy.) 


1 In this work we refer all network units as “switches” for consistency to 
SDN terminology. 
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2) PYCRO also preserves the autonomy and local policies 
of domains. A domain can independently determine whether 
and how to forward different flows and these preferences are 
unknown to other domains. 

3) PYCRO is efficient in both computation and communi¬ 
cation costs. 

PYCRO is the first work of privacy-preserving cross¬ 
domain routing optimization in SDN environments. We have 
implemented a prototype system that runs PYCRO on ma¬ 
chines in a campus network. Experimental results using real 
ISP network topologies show that PYCRO has reasonably good 
efficiency. It spends < 30 seconds and < 700 KB messages 
in computing a shortest path tree for networks consisting of 
thousands of switches and links. 

The rest of this paper is organized as follows. We review 
the related work in Section [TT] In Section [Till we introduce 
the problem overview and background. We presenting the 
PYCRO protocol in Section IIV1 and then introduce some 
optimization techniques in Section [V] We design the bandwidth 
allocation protocol with our PYCRO protocol in Section [VT1 
In Section 1 VIII we justify the privacy-preserving property 
of PYCRO. We evaluate the performance of our protocol in 
Section IVIIII Finally, we conclude our paper in Section [IXJ 


II. Related Work 

Privacy-preserving cross-domain routing can be modeled 
as a secure multi-party computation (SMPC) problem. Yao’s 
seminal work |[30l introduces the first algorithm, called Yao’s 
garbled circuits, to allow two parties to compute an arbitrary 
function with their inputs without revealing private infor¬ 
mation. Since then, many studies about SMPC have been 
conducted j2j, 0, fl4l . fl6l . lH9l . In ITTl . a secure two- 
party computation system called Fairplay is introduced and 
the system implements generic secure function evaluation. 
FairplayMP proposed in 0 supplements the Fairplay sys¬ 
tem. FairplayMP is a generic system for secure multi-party 
computation while Fairplay only supports secure two-party 
computation. SEPIA 0 is a recently proposed SMPC system 
for general inter-domain network applications. A common 
limitation of these SMPC solutions is that the computation time 
can be way too long for practical applications. For example, 
0 shows that it takes thousands of days to track cross¬ 
domain connectivity of a few domains using SEPIA 0. An 
SMPC-based routing algorithm proposed to replace BGP also 
experiences long execution time HI which makes the existing 
SMPC methods impractical for inter-domain routing. 

Recently researchers have proposed custom privacy¬ 
preserving algorithms for different network applications. Chen 
et al. a use Bloom filters to combine access control lists 
of multiple domains and determine network reachability in a 
privacy-preserving manner. Djatmiko et al. 0 propose to ap¬ 
ply counting Bloom filters for privacy-preserving multi-domain 
connectivity tracking. STRIP flZl is a privacy-preserving inter¬ 
domain routing protocol to replace BGP and achieve fast 
convergence. To our knowledge, no existing work in this 
category studies the privacy-preserving cross-domain routing 
optimization problem. 


III. Problem Overview and Background 

In the section, we formalize the problem in this paper and 
then introduce a novel cryptographic tool we will use to solve 
the problem. 

A. Problem Formulation 

We formalize the problem to be solve in this paper as 
follows. 

Consider a large network that consists of N domains: D i, 
D-2, ..., Dm, where each domain I), has a domain controller 
Ci that makes routing decision and updates the forwarding 
tables of switches in the domain. A domain controller can 
access any information of its domain, including the network 
topology, access control policies, link bandwidth, and authen¬ 
ticated hosts. A domain controller can add, delete, and update 
forwarding entries of switches in its domain. It communicates 
with controllers in other domains via pre-established secure 
channels. 

For any two switches v. v' £ Di (v ^ v'), we use v ~ 
v' to denote that there is a link between v and v' and we 
denote its link cost by c(vv'). Clearly, each Ci should know 
the topology of Di, and should also know all the link costs 
within this domain: {c(vv')\v,v' € Di,v ^ v'}. We assume 
that the intra-domain topology and the intra-domain link costs 
are all private information of Ci. That is, any other domain 
controller should not know anything about this topology or 
these link costs. We assume different domains are managed by 
different parties, such as ISPs, organizations, or departments 
of a corporation. Parties do not share domain information. If a 
party owns multiple physical domains, all these domains can 
be considered a single logical domain in this problem. 

There are some inter-domain links that connect switches 
from different domains. We assume that information about an 
inter-domain link is available of the two end domains, and 
domains can share it with other domains. That is, for any inter¬ 
domain link vv' (where v € Di, v' £ Dj and Di ^ Dj ), all 
domain controllers could know the two endpoints v and v' , and 
also Di and l ) :l —the domains they belong to. A switch that 
is connected to switches in other domains is called a gateway 
switch. We assume gateway switches are publicly known. 

Suppose that there are a source switch v s , which belongs 
to a domain D s , and a destination switch v t , which belongs 
to another domain D t . Our objective is to design a private¬ 
preserving optimized routing solution. Specifically, we need 
to design a protocol that allows each domain controller Ci to 
find the forwarding table T(v) for all v £ Di, where each 
entry T(v)[v s ,vt] is the next-hop switch of v on the optimal 
routing path from the source v s to destination v t . 

In this work, PYCRO focuses on two major routing opti¬ 
mization problems. 

1) Policy-compliant shortest path routing. Each link has 
an associated routing cost (also known as link weight), rep¬ 
resenting a performance metric such as hop count, latency, or 
traffic load li28l . The routing object is to find a path from the 
source to the destination that has the minimum sum of link 
cost without violating policies of domains. 
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2) Bandwidth allocation. Bandwidth allocation has been 
applied to practical traffic engineering solutions such as B4 
115]. Each flow has a bandwidth demand and link bandwidth 
is allocated to different flows. When flows are competing for 
bandwidth, a single flow may need multiple paths to satisfy its 
bandwidth demand. The routing object is to find one or more 
paths for a flow such that the flow bandwidth demand can 
be satisfied. At this stage, we do not consider fairness among 
flows fl5l . 

Security and Privacy Requirements. Due to security 
concerns, a switch only allows its domain controller to install, 
delete, or update forwarding table entries. Domains may not 
wish to reveal their information including network topology, 
link bandwidth, and routing policies. In addition, a domain 
should have routing autonomy to determine whether and how 
to forward a given flow. This preference should also be made 
confidential to other domains. 


B. Cryptographic Tool 

Here we introduce the cryptographic tool we will use in 
this work, namely the Secure-If operation. 


IV. Design of the PYCRO Protocol 

In this section, we present the PYCRO protocol with three 
steps:equivalent cost graph construction, privacy-preserving 
shortest path tree protocol and path establishment. In the PY¬ 
CRO protocol, we need two homomorphic encryption systems 
E() and E'(), both of which must be semantically secure. 
The difference between E() and E'Q is that E() must be 
additively homomorphic, while E’ () must be multiplicative 
homomorphic. Specifically, for two messages x and y, 

E(x) + E(y) = E{x + y) 

E'(x) ■ E\y ) = E'(xy) 

All E () and E'Q encryption operations in this paper use a 
public key whose corresponding private key is shared among 
the domain controllers using (TV, 2)-secret sharing. There exist 
cryptosystems (9), (27), 1251 that are both additively and mul- 
tiplicatively homomorphic. However, we do not use them due 
to efficiency considerations. We denote by DQ and D'Q the 
corresponding decryption operations, respectively. In addition, 
we allow both of them supports re-randomization operations, 
and the rerandomization operation is denoted by RQ and R'Q. 
As mentioned earlier, another main cryptographic tool we use 
in the PYCRO protocol is the Secure-If operation. 


Secure-If operation. Our protocol depends on a crypto¬ 
graphic technique developed by us, which we call the Secure- 
If operation. This operation allows the protocol to choose 
between two options Y and Z, based on whether a partic¬ 
ular condition X is satisfied. Denote by SecIf(X, Y, Z) the 
Secure-If operation, and then we have 


SecIf[X,Y,Z] 


(Y, X is satisfied ; 
\Z, otherwise. 


(1) 


Note that this operation is privacy preserving. It is infeasible 
for anybody to decide whether the condition is satisfied or 
not, i.e., which of the two options is actually chosen. For 
example, suppose that X, Y, Z are ciphertexts; consider a 
condition that “X is an encrypted 1”. This operation can return 
a rerandomization of Y when the plaintext of X is indeed 1, 
and return a rerandomization of Z otherwise. However, nobody 
can learn whether the returned value is a rerandomization of 
Y or a rerandomization of Z unless the result is decrypted. In 
general, the privacy guarantee is that no knowledge about any 
plaintext(s) involved is leaked to any party. 


The involved conditions may be complicated and thus this 
technique itself can depend on other cryptographic building 
blocks. For instance, we may need to use the building block of 
partial decryption. Suppose that the private key for a ciphertext 
is shared among a number of parties using a secret sharing 
scheme mu . Partial decryption allows a party with a share of 
the private key to partially decrypt a ciphertext. The partially 
decrypted ciphertext does not leak any knowledge about the 
plaintext. However, when a threshold number of parties apply 
partial decryption one by one, the plaintext will finally be 
revealed. Detailed implementation of Secure-If operations are 
custom-built and depend on different algorithms. 


Also notice that we will use a few variants of this technique 
in this paper. Each of these variants is constructed in a distinct 
way. Please see Section HV-DI for the detailed constructions. 


A. Equivalent Cost Graph Construction 

In this subsetion, we show how to construct the equivalent 
cost graph. To construct equivalent cost graph, we first show 
the nodes in it and then the links in it. 

As for nodes, we define a switch as a significant node if 
it is the source switch or a gateway switch and the nodes of 
the equivalent cost graph are the significant nodes in the entire 
network. We denote by Si the significant node set of domain 
Di and we also denote by S the significant node set of all 
domains. 

As for links, for any two significant nodes v and v' (v f 
v'), we distinguish two cases: 

Case 1: If v, v' £ Si, then link v ~ v' is in the equivalent 
cost graph.In this case, the link is called intra-domain link 
since two nodes are in the same domain. Note that a intra¬ 
domain link does not necessarily correspond to a physical link, 
and could be a multi-hop path between two switches. The path 
from v to v' is selected by Di in the best effort based on 
DQ s local policies and is not necessarily the shortest path. If 
a domain does not wish to forward /, it sets the path length 
as infinity or the pre-defined path length upper limit. We use 
d(vv') to denote the path length assigned by Di. 

Case 2: If v £ Si A v' £ Sj A Si ^ Sj A v ~ i/then link 
v ~ v' is in the equivalent cost graph.In this case, the link 
is called inter-domain link since two nodes are in different 
domains. We use c(W) to denote the length of link v ~ v'. 

As an example. Figure [T(a)| shows the equivalent cost graph 
of a network consisting of four domains, in the view of the 
controller C s of the source domain D s . The nodes of the graph 
are the source switch v s and all gateway switches Vi-f. 

Clearly, C s , the controller of the source domain, knows 
the connectivity information of the equivalent cost graph. 
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(a) Equivalent cost graph of four domains: (c) PSPT and path establishment 

dashed lines are intra-domain links and solid 
lines are inter-domain links. 


Figure 1. An illustration of the PYCRO protocol. 


Furthermore, for links in Case 2 above, C s also knows the 
link costs in the equivalent cost graph. For links in Case 1 
above that are not in D s , C s does not know the link costs 
in the equivalent cost graph, which are private information of 
different domains. 

B. Privacy-preserving Shortest Path Tree Protocol 

This subsection describes how the source controller com¬ 
putes a Privacy-preserving Shortest Path Tree (PSPT) on the 
equivalent cost graph rooted at v s while providing strong 
protection for the private information of other domains. We 
use c max to denote the maximum link cost and assume the 
length of cryptographic keys in use is much greater than the 
length Of C m ax- 

Each domain controller C-, , except the source domain 
controller C s , encrypts all its link costs in Case 1 of the 
equivalent cost graph, and sends them to C s - Specifically, for 
any two switches v and v' in Di ( Di ^ D s ), C\ computes 
e(vv') = E(d(vv')) and sends it to C s . The source domain 
controller C s needs to encrypts all its link costs in Case 
1 of the equivalent cost graph. C s is also responsible for 
encrypting the link costs in Case 2 of the equivalent cost 
graph. Specifically, for any v in I), and v' in Dj, if there is an 
inter-domain link between these two nodes, then C t computes 
e(vv') = E(c{vv')). For any v, v' g I) s (» / v'), if there is an 
intra-domain link between these two nodes, then C) computes 
e(vv') = E{c{vv')). 

For each node v in the equivalent cost graph, except the 
source node itself, C s computes three indicators: f(v) = 
E'( 2), g{v) = E( 0), and h(v ) = £"(</>). Here f{v) is an 
encrypted indicator for node v, indicating whether it has been 
added to the shorted path tree. We use an encrypted 2 to 
represent “No”, and an encrypted 2~ 1 to represent “Yes”. The 
plaintext of g(v) will be used for the length of the shortest path 
from the source node to v, once v is added to the shortest path 
tree. The plaintext of h(v) will be used to store the information 
of the parent node of v in the shortest path tree, once v is added 
to the shortest path tree. All these indicators are essential in 
the computation of the shortest path tree. 

For the source node, C s computes the three indicators: 
f(v ) = E'( 2 _1 ), g(v) = -E'(O), and h{v) = E'((f>), because it 
is the root of the tree. Then the source controller repeats the 
two steps below for |Sj — 1 iterations, where S is the set of 
nodes in the equivalent cost graph. At each iteration, a node 


with the minimum distance to the root among the remaining 
nodes is added to the tree. 

Step 1. For each link vv' in the equivalent cost graph, C s 
uses a Secure-If operation (denoted as Seclfo ) to compute 
a(vv'). The condition here is that the plaintext of f(v) is 
equal to the plaintext of f(v'). If this condition is satisfied, 
a(vv') = E(c max \S\ + 1); otherwise, a(vv') = R{g(v) + 
g(v') + e(vv'))). If the condition is satisfied, it means either 
v' and v are both in the tree or neither in the tree. We just 
let a(vv') be a maximum value and do not consider it. If the 
condition is not satisfied, one of v' and v is in the tree and the 
other is not. Then the plaintext of a(vv') is the distance from 
the node not in the tree to the root. 

Step 2. For each link vv 1 in the equivalent cost graph, C s 
uses a Secure-If operation (denoted as Seclfi ) to re-compute 
f{v), /(?/), g(v), g(y'), h(v), h(v'). The condition is that the 
plaintext of a(yv') is the smallest among the a values of all 
links in the equivalent cost graph. The node not in the tree 
that corresponds to the smallest a should be added to the tree 
and its three indicators should be updated. 

If the condition in Step 2 is satisfied, then we use another 
Secure-If operation (denoted as Seclf 2 ) to decide how to 
update the indicators. The condition of this new Secure-If 
operation is that the plaintext of f(v) is equal to 2 , i.e., whether 
the node v is not in the tree. 

• When the condition is satisfied (v is not in the tree), 
f(v) = E'( 2 _1 ), g(v) = R(a(vv’)), h(v) = E'(v'). 
The indicators of v' are re-randomized. 

• Otherwise, v' is not in the tree, hence f(v') = 
E'{2~ 1 ), g{v') = R{a{vv')), h{v') = E'(v). The 
indicators of v are re-randomized. 

If the condition in Step 2 is not satisfied, all indicators 
f(v), f(v'), g(v), g{v'), h(v), h(v') are just re-randomized 
based on the original values. 

We show an example of the above iteration in Figure |l(b)| 
v s , v\, and v? are already in the tree. Since V 3 is not in the 
tree, we compute a(v 2 V 3 ) = R{g(v 2 ) + g{v 3 ) + e{v 2 V 3 ))) = 
R(E( 1) + E( 0) + E{ 2)) = R{E{ 3)). Suppose the plaintext 
of a(v 2 V 3 ), i.e., 3, is the smallest a value. Then v 3 should be 
added to the tree. The indicators of v 3 are updated as follows: 
f(v 3 ) = E'{ 2" 1 ), g(v 3 ) = R(E( 3)), h(v) = E'(v 2 ). The 
indicators of V 2 are all re-randomized. 
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The detailed algorithm specification of the PSPT con¬ 
struction protocol is not shown due to space limit. Once the 
algorithm is completed, for each v in the equivalent cost 
graph, C s actually obtains the ciphertexts of g(v), the shortest 
path length from v s to v, and h(v), the parent of v on 
the PSPT. Figure |l(c)| shows the constructed PSPT of the 
network. With all the g(v) and h(v), we can construct the 
path from v s to v t using the method proposed in the next 
section (Section [iV-Cl l. Note that we use three types of Secure- 
If operations (Seclfo, Seclfi and Seel fa). We will describe 
how they are implemented in detail in Section HV-DI 

C. Path Establishment 

After running the PSPT construction protocol, each domain 
controller knows all its significant nodes’ values of g and h 
from C s . Using the values, we can construct the path P from 
Vt back to v s step by step (e.g., first Vt, and then the parent 
of vt, and then the parent of the parent of vt, until the source 
V s ). 

After finishing computing the shortest path tree, C s then 
partially decrypts each g{v) and each h(v), and sends the 
partial decrypted ciphertexts to the domain controller of node 
v. The domain controller of v also applies partial decryption, 
and thus obtains the plaintexts of g[v) and h(v), i.e., dg(v) 
and dh{v). Since E() uses (N, 2)-secret sharing, the encrypted 
indicators can be decrypted by partial decryption of two 
domains. 

For any destination v t , the shortest path and corresponding 
forwarding table entries are constructed using Algorithm Q] 
with all plaintext indicators dg() and dh(). 

If vt is not a significant node, the domain controller Ct 
of vt compares all the significant nodes in its domain, for 
the sums of their distances from v s and to v f . Suppose the 
significant node with the smallest distance sum is v. Then 
the intra-domain path from v to v t is chosen as part of the 
shortest path from v s to v t , and the forwarding table entries 
for destination vt in this part of path are computed and installed 
accordingly. The forwarding table entries in the other parts of 
the path are computed in a way similar to vt being a significant 
node presented below. 

If Vt is a significant node, the domain controller of v t 
decides what to do based on the type of link between vf s 
parent dh{vf) on the shortest path tree and v t in the equivalent 
cost graph. 

• If the link represents an intra-domain path, i.e., dh(vt ) 
is another significant node in the destination domain, 
the intra-domain path between dh{vfj and v t is picked 
as part of the shortest path from v s to v t . The forward¬ 
ing table entries for destination v t in the destination 
domain are installed by Ct accordingly. 

• If the link is an inter-domain link, the link is added 
directly as part of the shortest path from v s to v t . 
Ct then sends a message to the domain controller of 
dh(vt ) and asks it to install a corresponding forward¬ 
ing table entry at switch dh(vt). 

Next, the domain controller of the predecessor of the des¬ 
tination domain on the selected shortest path computes the 


forwarding table entries similarly. This process is repeated until 
the source switch is reached and all forwarding table entries 
for destination vt have been computed. 

For the example of Figure |l(c)| the destination controller 
Ct selects vq as part of the optimal path from v s to v t . It 
then installs forwarding entries on switches between v t and vq 
and also notifies C\ to install a forwarding table entry at V 4 , 
specifying that packets from v s to v t should be forwarded to 
vq by 114 . The routing path can be established by repeating this 
process. 

Algorithm [I] presents the pseudocode of the path establish¬ 
ment protocol in Section IIV-CI 


Algorithm 1 Path Establishment Protocol 
Input: All significant nodes’ g and h; 

Source node v s and destination node v t ; 

Output: The shortest path P from v s to v t 
1 : C s computes partial decryption PD(g(v)) and 
PD'(h(v)), and then sends them to C, the controller of 
v. 

2: C partially decrypts PD(g(v)) and PD'(h(v)) and gets 
the plaintext of g{v) and h(v): dg{v) and dh{v). 

3: V t = V t 

4: if vt S then 

5: Let St be the significant node set of D t 

Vmin — 1 , dmin — OO 

7: for all v G S t do 

8: if dg(v) + d(vv t ) < d m i n then 

9: d min = dg(v) + d{wf), Vmin = V 

10 : end if 

11: end for 

12 : Add the intra-domain path from v m i n to v f to P. 

13: Let Vt. = Vmin 

14: end if 

15: Now we construct the path from v s to Vt- 

16 : while v t f v s do 

17: if dh{vf) £ St { dh{vt ) ~ vt is an intra-domain link} 

then 

18: Add the intra-domain path from dh(vf) to Vt to P. 

19: end if 

20 : if dh(yf) St {dh(vf) ~ v t is an inter-domain link} 

then 

21 : Add dh(vf) ~ vt to P. 

22 : end if 

23: Let vt = dh{vf) 

24: end while 


D. Implementation of Secure-If Operations 

In this section, we will introduce the implementation of 
the three Secure-If operations used in the PSPT construction 
protocol. 

First, we present a sketch of the Secure-If operation (See 
Algorithm |2}. Each Secure-If operation needs to construct 
three parameters (£q ; L. £ 2 ) and a condition satisfied value x 
as input, to is a condition while t\ and £2 are two options. The 
output of Secure-If is t\ when condition is satisfied (£ 0 = x); 
otherwise, the output is £ 2 . Such operation is achieved by an 
interactive process between two controllers, say C s and Ci. 
C s first applies partial decryption to £ 0 and sends the result 
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Algorithm 2 Secure-If Operation Sketch 


Input: 

x: value when condition is satisfied; 

(to,ti,t 2 ): three parameters. 

C s randomly choose a domain controller C,. 

C s computes PD(to) and sends (PD(t 0 ), t 1; t 2 ) to C\. 
{PDQ is partial decryption operation} 

Upon receiving (PD(to), t\, t 2 ), Cj do partial decryption 
on PD(to) and gets the plaintext dto of to. 
r R(t\) if dto == x 
^R(t 2 ) otherwise 
C s gets the result. 


1 : 

2 : 


4: C, sends 


back to C, 


PD(to), together with t \ and t 2 , to any other domain controller 
Ci. Then Ci can fully decrypt to and get the plaintext dto as the 
threshold of secret sharing is 2. C, verifies whether dto is equal 
to x and replies one of t\ and t 2 (with re-randomization) to 
C s . With the Secure-If operation sketch, we need to show the 
construction of (to, t\, t 2 ) and x when we introduce a Secure- 
If operation. 

The PSPT construction uses three Secure-If operations 
( Seclfo , Seclfi, and Seclfi). As the Secure-If operation 
Seclfi is used in Seclfi, our decryption is in the order of 
Seclfo, Seclfi, and Seclfi. 

Construction of Seclfo 

x in Seclfo is 1 and (to, t\, t 2 ) are constructed as follow. 

With probability }, C s computes to = (jj^)Y- where r 
is a randomly picked exponent^; ti = E(c max \S\ + 1); t 2 = 
R(g(v) + g(v') + e(vv')). In this case if f(v) is equal to f(v’), 
to = 1 = x, hence the function of Seclfo can be achieved. 

With the remaining probability }, C s computes to = 
( /(«)/(«') f’ w ^ ere r * s a randomly picked exponent; t\ = 
R(g(v) + g(v') + e(vv')); t 2 = E(c ma x\S\ + 1). In this case 
if f(v) is not equal to f(v'), to = 2 A /2 = 1 = x, hence the 
function of Seclfo can also be achieved. 

The reason for that we use an uncertain calculation is to 
protect privacy. If we only apply the first case, any attacker that 
decrypts to and finds to = x can determine that f(v) = f(v'). 
However, in the current implementation, even if an attacker 
knows to = x, it cannot guess whether f(v) = f(v') as f(v ) = 
f(v') and f(v ) Y f(v') have equal probability. 

Construction of Seclf 2 

x in Seclf 2 is 2 and (to,t\,t 2 ) are constructed as follow. 

With probability i, C s computes to = R(f(v)). 

Let ti,t 2 be E'(2~ 1 ),R'(f(v)) for the Seclfi of f(v)\ 
R(a(vv')),R(g(v)) for g(v)\ E'(v'), R'(h(v)) for h(v)\ 
R'(f(v')),E , (2~ 1 ) for f(v'); R(g(v')), R(a(vv')) for g(v'); 
R'(h(v')),E'(v) for h(v'). 

With the remaining probability i, f 0 = anc * 

the above values of t\ and t 2 are swapped, i.e., ti,t 2 be 
E'(f(v)),E'( 2 _1 ) for f(v) and so on; 

2 Assume the plaintext space and the ciphertext space are both the same 
cyclic group. The value of r needs to be picked uniformly at random from 
between 0 and the order of the group minus 1, including the two endpoints. 


Construction of Seclf 1 

Here we show the construction of x and (to, t-[, t 2 ) in 
Seclfi. We first introduce a comparison protocol called osc 
which is necessary in Seclfi. 

The comparison protocol is designed by us based on the 
secure comparison protocol proposed in l20l . The protocol 
in ESI takes two ciphertexts of E( ) as input, and outputs 
another ciphertext of E(). The output is E( 1) if the first 
input’s plaintext is greater than or equal to the second input’s; 
otherwise, the output is E(— 1). Based on this comparison 
protocol, we design a new comparison protocol which can 
distinguish not only two edges with different a but also two 
edges with the same a by comparing their indexes. Denote the 
original comparison operation by sc(). Assume that the two 
edges’ a values are a and b and their indexes are a u ix and 
bidx' 

The protocol we designed, osc(a,aid x ,b,bid x ), is actually 
a Secure-If operation. Its a; is 1 and (to,ti,t 2 ) are constructed 
as the following paragraph. With x, (to,ti,t 2 ) and Secure-If 
operation sketch, we get the new protocol osc. 

First we compute 6 = sc(a, b) + sc(b, a) — E( 1 ). If a ^ 
b, 6 is E(— 1); Otherwise 0 is ^(l). With probability i, C s 
computes to = 9; ti is E( 1 ) if aidx < bid x \ Otherwise ti 
is E(— 1); t2 = sc(b,a). With probability C s computes 
t 0 = — 9; tl = sc(b,a)', t 2 is E( 1) if a^x < b^x'. Otherwise 
t 2 is -E(-l). 

With the secure comparison, C s can compare each a value 
(except a(vv') itself) with a(vv'). Denote by f3i the output of 
the protocol. Suppose that there are f such outputs in total. C s 
computes 7 = Yl, Pi, an d uses the secure comparison protocol 
again, to compare 7 with E(f). Let e be the output. With e, 
we can easily construct to,ti,t 2 of Seclfi. 

The construction of Seclfi is shown in Algorithm [3] 


Algorithm 3 Construction of Seclfi 
Output: x and (to,ti,t 2 ). 

1 : Denote by m the total link number in the equivalent cost 
graph, (the link number is equal to the number of all a 
values.} 

2 : Assume the index of a(vv') is k. 

3: 7 = .E(0),C = TTl — 1 

4: for * = 1 to TO do 

5: Assume the ith link is 17 ~ v 2 . 

6 : if k Y i{vl ~ v 2 Y v ~ v '} then 

7: 7 = 7 + osc(a(vv'), k, a(viv 2 ), i). 

8 : end if 

9: end for 

10 : e = osc( 7 , E(f)). 

11 : Let t a be the result of Seclfi. 

12 : Let 4 be : 

t b =< R'(f(v)), R(g(v)), R’(h(v)), 

R'(f(v')),R(g(v')),R'(h(v')) > 

13: C s computes: 

(to = e, ti = t a , t 2 = t b ; with probability 
\t 0 = —e,ti = t b ,t 2 = t a ;with probability i 
14: x = l. 

15: C s gets x and (to,ti,t 2 ). 
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V. Protocol Optimization 


In this section, we introduce two optimization methods of 
PYCRO. The first method reduces the number of shortest path 
tree computing for different flows. The second method reduces 
the computing time of each shortest path tree, called PYCRO 
with Candidate Recommendation (PYCRO-CR). Combining 
these two, the efficiency of PYCRO can be significantly 
improved. 

A. Shared Shortest Path Tree 

For all flows transmitted from a domain D s , it is highly 
possible that another domain will treat these flows or a large 
subset of these flows using the same access and routing policy. 
We define an equal-flow group G as a group of flows from the 
same domain such that for all flows in G, any other domain 
D will treat them using the same access and routing policy 
and hence provide the same paths between any two gateways 
of D. Therefore all flows in G can use a number of shared 
shortest path trees. 

A source domain with k gateway switches maintains k 
shared shortest path trees for each equal-flow group. Each 
of the trees is rooted at a gateway switch. To compute each 
shared shortest path tree, the nodes of the equivalent cost graph 
include gateway switches (significant nodes) of all domains. 
Correspondingly, when constructing links in the equivalent cost 
graph, for any two significant nodes v and v' (v v'), we 
distinguish two cases: 

• Case 1: v and v' belong to the same domain, then 
there is a link in the equivalent cost graph between 
those two nodes, and the cost of this link is d(vv'), 
which is only known to the domain of v and v'. 

• Case 2: v and v' belong to different domains. If there 
is an inter-domain link between v and v', then there 
is a link in the equivalent cost graph between those 
two nodes, and the cost of this link is c(vv'). If there 
is no such inter-domain link then there is no link in 
the equivalent cost graph between these two nodes. 

Then the algorithm in Section HV-BI can be run to build each 
shared shortest path tree. 

When the source controller receives a flow query from 
the source v 8 to destination Vt- For each gateway switch Vi 
in the source domain, the source controller C s computes the 
encrypted distance from v s to v, plus the distance from •<;, to a 
gateway w in the destination domain on the shared tree rooted 
at Vi. Thus for any w, there are k potential paths from v s to 
w. Suppose the destination domain has /;•' gateways. Then C s 
simply sends all k ■ k! path lengths, with partial encryption, 
to the destination controller Ct■ Ct can determine the shortest 
path from v s to v t and install forwarding entries using the 
method similar to that in Section IIV-CI 

For example in Figure |l(a)| both D s and D t have two 
gateways. Hence for a group of flows from D s , D s can 
maintains two PSPTs rooted at v± and V 2 - There are at most 
2x2 = 4 shortest paths between D s and D t , and D s can 
select one of them for each flow. Due to space limit, we do 
not present further details of path selection and forwarding 
entry installation in other domains. 


B. PYCRO with Candidate Recommendation 

The complexity of the shortest path tree algorithm pre¬ 
sented in Section IIV-BI is mainly due to the number of calls 
of Secure-If operations to select the smallest a(vv') among 
the a values of all links in the equivalent cost graph and the 
inefficiency of the secure comparison operation. To reduce the 
number of calls of Secure-If operations, we propose to use 
candidate recommendation to let the other domain recommend 
potential nodes that may have the smallest a value(i.e.,the 
smallest a value in its domain). As for the inefficiency of the 
secure comparison operation, we replace it with the Damgard- 
Geisler-Kroigard (DGK) secure comparison protocol, a more 
efficient protocol proposed in 00 Unlike the secure compari¬ 
son we used in Section HV-B I the input and output of the DGK 
protocol are plaintexts. Suppose there are two parties A and 
B. A has a number a and B has a number b. A and B can 
run the DGK protocol to compare a and b without revealing 
a(b) to party B(A). 

After constructing the equivalent cost graph and adding the 
source node v s into the shortest path tree with g(v s ) = E{ 0). 
The source domain controller C s broadcasts v s and g(v s ) to all 
other domain controllers. Then, the domains repeat the three 
interactive steps below for IS 1 ) — 1 times: 

Step 1. Each domain D[ finds its significant node that is 
not in the shortest path tree and the path length to the root is 
the shortest in Di. D, also records the node’s parent and its 
path length. We call the node selected by Di a candidate node 
Vi. Besides, a domain controller Co (specified by the source 
controller C s ) sends the information g(v o) and h(v o) of its 
candidate node vq to C s . 

Step 2. The source controller C s should then find out the 
candidate node whose path length to v s is the shortest. G s 
temporarily sets Vq as the shortest-distance node u -t— vo- 
For each candidate node v t except vo'. Controller G s sends 
a message including g(u) to Vi s controller CV Ci then runs 
DGK secure comparison protocol to compare g(u) and the path 
length of candidate node Vi. Once the DGK protocol finishes, 
Ci tells C s the result of the comparison. According to the 
result, if the plaintext of g (it) is less than that of g(vi), Ci 
then updates u Vi. 

Step 3. After the two steps above, the controller C s get the 
shortest-distance node u. Next, C s requests the controller of 
it’s domain for the information of g(u) and h(u) and add u 
into the shortest path tree under its parent. C s broadcasts the 
new shortest path tree with encrypted distance information to 
the other domains. 

After |5| — 1 iterations of the above loop, C s finishes the 
computing of the shortest path tree. 

VI. Bandwidth Allocation 

Bandwidth allocation has been applied to practical traffic 
engineering solutions such as B4 US). We solves a relatively 
simple version of the bandwidth allocation problem. Before 
we define the problem, we introduce some preliminaries. 


3 Using DGK, we make a small sacrifice of privacy for efficiency. However, 
it's worth since only a little information is revealed. 
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Besides the link cost, every link vv' also has a bandwidth 
b(v,v'). b(v,v') represents the maximum bandwidth that link 
vv' can provide. And the definition of the cost of a flow on a 
path is: 

Definition 1: Given a path p from node v to node v' whose 
length is l p , if a flow / consumes bandwidth bf on p, then the 
cost of / on p is is c(f,p) =bf ■ l p . 

A flow / has a bandwidth demand qf. However as link 
bandwidth is limited, it may need multiple paths to satisfy a 
flow’s bandwidth demand 1131 . We assume a flow can be split 
to multiple subflows to be transmitted on different paths. And 
the cost of / is defined as: 

Definition 2: The cost of / for bandwidth allocation is the 
sum of path cost E bf ■ lp for p € P where P is the set of 
paths that / is split on. 

Given Definition Q] and Definition [2]we define the Band¬ 
width Allocation problem as follows: 

Definition 3: Bandwidth Allocation:fov any flow / with 
bandwidth demand qf, we should find k paths such that the 
sum of allocated bandwidth of these paths to / is no less than 
the bandwidth demand qf and the routing cost of / should be 
minimized. 

We design a bandwidth allocation protocol of PYCRO, 
named PYCRO-BA, works in the following steps: 

Step 1. During the construction of the equivalent cost 
graph, each domain controller assigns an available bandwidth 
b(v, v') amount between two significant nodes v and v', which 
is also encrypted by a homomorphic encryption system. 

Step 2. The source controller creates the shortest path tree 
and finds the shortest path p from the source v s to destination 
Vt using the protocol presented earlier. 

Step 3. The source controller determines the available 
bandwidth b p on the shortest path, which is the minimum value 
of b(v,v') for all links (v,v r ) on the paths. This process is 
similar to the previous protocol to determine the minimum 
cost candidate. We skip the protocol details here and have 
implemented them in the experiments. 

Step 4. If b p is smaller than the bandwidth demand q, C s 
computes a residual demand q — b p and find another path to 
satisfy the demand. 

Step 5. C s deletes all links of p from the equivalent cost 
graph, and repeats Steps 2-4 to find more paths until the 
bandwidth demand is satisfied. 

The above bandwidth allocation protocol requires multi¬ 
ple calls of the shortest path tree protocol. To improve its 
efficiency, C s may find multiple disjoint paths to different 
gateways of the destination domain and suggest these paths 
to the destination controller Ct . If Ct can also find multiple 
disjoint paths from different gateways to v t , multiple paths 
can be established by a single call of the shortest path tree 
protocol. We plan to develop more sophisticated protocol to 
optimize this process in future work. 

VII. Privacy analysis of PYCRO 

We analyze the privacy-preserving property of PYCRO in 
a standard cryptographic model, the semihonest model [Toj, 


which is widely used in the literature (e.g., ||29l and 0 ). 
In this model, all involved parties are assumed to follow 
the protocol faithfully, although they may attempt to violate 
privacy using the information they obtain. Note that such 
an assumption is acceptable in our scenario of cross-domain 
routing, because domain controllers usually have long-term 
relationship with each other. Despite their curiosity about 
others’ private information, it is uncommon for them to deviate 
from the protocol just in order to violate others’ privacy. 

The main result we get as shown in Proposition 4 below, 
is that PYCRO only leaks to each domain controller its 
significant nodes’ distances from the source node and parents 
nodes in the shortest path tree. We stress that this leaked 
distance information is about a small number of pairs of nodes 
only. Any other information, including distances between other 
pairs of nodes, are protected by PYCRO. Furthermore, our 
protection is cryptographically strong, i.e., no partial knowl¬ 
edge about the protected information is leaked by PYCRO. 
In contrast, the performance cost we pay for the privacy 
protection is very reasonable. The execution time varies among 
different topologies, from seconds to tens of seconds (please 
see Section IVIIIl for details). 

Proposition 4: PYCRO is weakly privacy preserving in the 
semihonest model, in the sense that it reveals to each domain 
controller no more than its significant nodes’ distances from 
the source node and parent nodes in the shortest path tree. 

The basic idea of our proof is to demonstrate a probabilistic 
polynomial-time simulator according to the definition and 
proof methodologies of cryptographic protocols discussed in 

ED- 

Proof Sketch: Due to limit of space, we only provide a proof 
sketch. Some details are skipped. 

Our proof is established by demonstrating a probabilistic 
polynomial-time simulator according to the definition and 
proof methodologies of cryptographic protocols discussed in 

ED- 

For each domain controller Ci, we construct a simulator for 
its view, which takes as input its significant nodes’ distances 
from the source node and parent nodes in the shortest path 
tree. All coin flips in the view can be easily simulated, and 
thus we focus on generating simulated messages below. 

If Ci 7 ^ C s , the simulator simulates the messages received 
from C s for each of its significant node, using two ciphertexts. 
The first ciphertext is an encrypted distance of the significant 
node from the source node, where the cryptosystem used is 
E() and the key used is Cf s own public key. The second 
ciphertext is an encrypted identity of the significant node’s 
parent node in the shortest path tree, where the cryptosystem 
used is E '() and the key used is still Cf s public key. 

For C\, we add the following simulated messages. In the 
Secure-If operation Seclfo, the messages from C s is simulated 
using three ciphertexts. The first of these three is under E' (), 
with the plaintext being 1 with probability or a uniformly 
random number with probability 1. The remaining two are 
encryptions of random plaintexts under E(). The public key 
used for encryption of all these three is Cj ’s own public key. 
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For the Secure-If operation Seclfi and Seel f 2 , the simu¬ 
lator goes as follows. For Seelf 2 , the messages from C s are 
simulated using 8 random ciphertexts under E'Q and 4 random 
ciphertexts under E(), and also another ciphertext under E'() 
with the plaintext being 2 or 1 , each with probability where 
the public key used for encryption is Ci’s own public key. For 
Seclfi, in addition to simulating the received messages in the 
executions of secure comparison, the simulator simulates the 
earlier round of message from C s using three ciphertexts under 
EQ, with the first being an encrypted 1 or encrypted — 1, each 
with probability i, where the public key used for encryption 
is Ci’s own public key. The remaining two ciphertexts are 
randomly generated. The simulator simulates the later round 
of message from C s using 8 random ciphertexts under E'Q and 
4 random ciphertexts under E(), and also another ciphertext 
under EQ being an encrypted 1 or encrypted — 1 , each with 
probability i, where the public key used for encryption is Ci’s 
own public key. 

For C s , the simulator goes as follows. First, it simulates 
the first round messages from other domain controllers using 
random ciphertexts. For each pair of significant nodes in any 
other domain, there should be a random ciphertext under the 
cryptosystem EQ. Then the simulator proceeds to simulate 
the message received from Ci in the Secure-If operation 
Seclfo. This should again be a random ciphertext under the 
cryptosystem EQ. 

The Secure-If operation Seclfi and Seelf 2 are more 
complicated. For Seelf 2 , the messages from Ci can be 
simulated by using 4 random ciphertexts under cryptosystem 
E'Q and 2 random ciphertexts under cryptosystem EQ. For 
Seclfi , in addition to simulating the received messages in 
the executions of secure comparison, the simulator simulates 
the earlier message from Ci using a random ciphertext, being 
E( 1) with probability -7 and E{— 1) with probability 1. 
The final messages from Ci are simulated using 4 random 
ciphertexts under E'Q and 2 random ciphertexts under EQ. 

□ 

VIII. Performance Evaluation 

The most significant concern of a privacy-preserving pro¬ 
tocol is its computation and communication efficiency. In this 
section, we conduct experiments to evaluate the efficiency of 
PYCRO protocols. We have implemented a prototype system 
on seven Dell PowerEdge R720 servers with Linux operation 
systems. All servers are connected via a campus network. 
Each machine runs a program to emulate a controller. If the 
controller number is larger than seven, we may run multiple 
threads on a single machine. We configure the controller 
placement such that two neighboring controllers are in different 
machines. In all experiments, cryptographical operations are 
implemented using the Crypto++ library ( 6 ). 

We use the router-level topologies of seven real ISP net¬ 
works collected by the Rocketfuel project J26). The detailed 
information of the seven networks can be found in Table Q] 
and networks are identified as I to VII. Based on topology 
analysis, we set a number of routers as gateways. Based on 
the seven networks, we construct 30 multi-domain topologies 
in six groups as shown in Table QT| For example, topologies 
1 to 5 are constructed using the same domains I and II, but 
have different number of gateways and inter-domain links in 


Table I. INFORMATION OF THE SEVEN ROCKETFUEL TOPOLOGIES 


Network ID 

Network name 

# routers 

# links 

# gateways 

I 

AS 1221 

318 

758 

231 

II 

AS 1239 

604 

2268 

242 

III 

AS 1755 

172 

381 

61 

IV 

AS 2914 

960 

2821 

507 

V 

AS 3257 

240 

404 

89 

VI 

AS 3967 

201 

434 

110 

VII 

AS 7018 

631 

2078 

246 


Table n. INFORMATION OF MULTI-DOMAIN TOPOLOGIES. 


Topo ID 

# domains 

domains 

# inter-d links 

# gateways 

1-5 

2 

1,11 

10-100 

21 - 165 

6-10 

3 

I to III 

10 -100 

21 - 158 

11 - 15 

4 

IV to VII 

10-100 

21 - 177 

16-20 

5 

i,m,v to vii 

10-100 

21 - 174 

21 - 25 

6 

I to VI 

10 -100 

21-177 

26-30 

7 

I to VII 

10 -100 

21 - 185 


an increasing order. Gateways are randomly selected from the 
gateways routers of the Rocketfuel networks. 

Computation cost. We first conduct experiments to con¬ 
struct shortest path trees on every topology. For each topology, 
we randomly select 20 nodes and construct a shortest path tree 
for each of them. By computing time, we mean the average 
execution time of the protocol for one shortest path tree. We 
find that the computing times for different nodes in a same 
topology vary very little. It is because the execution time 
mainly depends on the number of domains, number of inter¬ 
domain links, and number of gateways. Figure [2] shows the 
average execution time of PYCRO on different topologies. 
The deviations are too small to be shown in the figure. We 
find that, for topologies consisting of the same domains (e.g., 
topologies 1-5), the execution time increases linearly with the 
number of inter-domain links and number of gateways. By 
comparing topologies of different domains, the execution time 
also increases linearly with the number of domains. In general 
PYCRO is very efficient: it takes a short time to compute a 
shortest path tree on a topology with thousands of switches 
and links in a privacy-preserving manner. Since a shortest path 
tree can be shared with multiple paths and the response to a 
path query takes much less time. Specially, if we have got a 
shortest path tree rooted at v s , the paths that start from v s to 
any destination can be constructed easily and quickly using 
the Algorithm Q] 

We then conduct experiments to evaluate the execution time 
of the bandwidth allocation protocol. We assign every link 
a random capacity from 1 to 5. In each experiment, we set 
the bandwidth demand as 20 and find multiple paths between 
the sender and destination to satisfy the bandwidth demand. 
This bandwidth demand can be considered as the aggregated 
demand of all flows in the sender switch. For each topology 
we perform 20 runs and compute the average. The results 
are shown in Figure [3] We find that there is no strict linear 
dependency of the execution time and number of inter-domain 
links, because more inter-domain links also make it easier to 
find multiple disjoint paths at a shortest path tree. 

Communication cost. We then show the communication 
cost of PYCRO in the average size of all messages per domain 
and plot the results in Figures Q] and 0 We observe that the 


9 




















Topology ID 


Figure 2. Average execution time 
of PYCRO 



Figure 3. Average execution time 
of PYCRO bandwidth allocation 



Topology ID 

Figure 4. Communication cost of 
PYCRO 



Figure 5. Communication cost of 
PYCRO bandwidth allocation 


communication cost also increases with the number of do¬ 
mains, number of inter-domain links, and number of gateways. 
Each domain spends less than 700 KB to compute a shortest 
path tree and less than 1 MB to allocate bandwidth for the 
largest topology. For other topologies the communication cost 
is much less. In general, PYCRO is communication efficient. 

Comparison with other solutions. It is hard to find an 

existing work achieving the same objectives as PYCRO. It is 
non-trivial to apply existing secure multi-party computation 
such as Fairplay OH and SEPIA 0| to the problems of this 
paper. 

A cross-domain privacy-preserving protocol for quantifying 
network reachability is proposed in 0. From their experi¬ 
mental results, we find that about 400 or 550 seconds offline 
computation cost, about 5 or 25 seconds online computation 
cost and about 450 or 2100 KB communication cost are needed 
for every party on average in their synthetic data. In our 
experiments of optimized protocol of PYCRO, even the biggest 
network requires only 32.3/7 = 4.61 seconds and 687.78/7 = 
98.25 KB for each domain in average. In fl7l . a full-fledged 
system called Fairplay that implements generic secure function 
evaluation is introduced. Their experimental results show that 
it takes 1.41 second to make a comparison. In our optimized 
protocol, (|Sj-l)(rc-l) comparison operations are needed in 
total, where |Sj is the significant node number (from tens to 
hundreds) and n is the domain number(from 2 to 7). Hence, 
if we apply Fairplay to our protocol, the average comparison 
operation time of each domain is 1.41(|S'| — 1)(zz — 1) seconds. 
For a case |Sj = 185 and n = 7, the average comparison time 
of each domain is 222.38 seconds while the average time that 
PYCRO consumes in each domain is 4.61 seconds. 

In summary, PYCRO can improve the time and bandwidth 
efficiency by an order of magnitude for cross-domain routing 
optimization, compared to existing solutions. 

IX. Conclusion 

In this paper we present PYCRO, the first privacy¬ 
preserving cross-domain routing optimization protocol in SDN 
environments. We develop a new cryptographic tool named the 
Secure-If operation and apply it with homomorphic encryption 
to compute the shortest cross-domain paths without revealing 
private information. PYCRO also provides bandwidth allo¬ 
cation, a fundamental traffic engineering solution. We have 
implemented PYCRO in a prototype system and performed 
real experiments to demonstrate its efficiency. Experimental 
results show that PYCRO can improve the time and bandwidth 
efficiency by an order of magnitude compared to general- 
purpose solutions. In future we will design more complex 
routing optimization functions based on PYCRO. We believe 


our study may lead to useful discussion of the same problem 
for the Internet. 
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